home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 12⁄22⁄89 / 0013-Re Multiple Inherita-Dec89 < prev    next >
Encoding:
Text File  |  1989-12-08  |  1.5 KB  |  37 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  ALCABES      to CPLUS.APPLE$ CP.ARCHIVES
  2.  
  3. Item    9847949                         1-Dec-89        20:27
  4.  
  5. From:   MIKE.VILOT                      ObjectWare, Michael Vilot,PRT
  6.  
  7. To:     D2022                           Strata, Gary Bringhurst,PRT
  8.  
  9. cc:     CPLUS.DEV$  Cplus.Apple$        C++ Interest List--Developers
  10.  
  11. Sub:    Re: Multiple Inheritance
  12.  
  13. >    The question is this:  is this style of programming simply obsolete when
  14. >multiple-inheritance is added to the language, or is there some way to avoid
  15. >the potential problems?
  16.  
  17. The short answer is: No, that style of programming is not obsolete.  You don't
  18. _have_ to use the multiple inheritance feature when it's not appropriate.
  19.  
  20. >potential for traversing the same nodes of the DAG more than once.  If class B
  21. >inherits from class A, and class C inherits from class A, and class D inherits
  22. >from classes B and C, what happens when we call class D's Draw method?  Does
  23. >call both B's and C's Draw methods?
  24.  
  25. Using multiple inheritance (at least with C++ public derivation) is stating
  26. that an object of class D is both "a kind of" B and "a kind of" C.  The best
  27. way to make this work without ambiguity is to make sure that B's and C's are
  28. really _different_ "kinds of" things.
  29.  
  30. That is, you probably don't want both paths to support a Draw() member
  31. function.  If the multiple base classes are really very similar, then
  32. inheriting from them is bound to cause ambiguity and/or end up calling the
  33. common base's member more than once.
  34.  
  35. Mike
  36.  
  37.